IBIS Macromodel Task Group Meeting date: 11 October 2022 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma * Jared James Google: Hanfeng Wang GaWon Kim Intel: * Michael Mirmak * Kinger Cai Chi-te Chen Alaeddin Aydiner Keysight Technologies: * Fangyi Rao Majid Ahadi Dolatsara Ming Yan Radek Biernacki Rui Yang Luminous Computing David Banas Marvell Steve Parker Mathworks (SiSoft): * Walter Katz Mike LaBonte Micron Technology: * Randy Wolff * Justin Butterfield Missouri S&T Chulsoon Hwang Yifan Ding Rivos Yansheng Wang SAE ITC Michael McNair Siemens EDA (Mentor): * Arpad Muranyi Teraspeed Labs: * Bob Ross Waymo: Zhiping Yang Zuken USA: Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Michael noted that there was a discussion on the Editorial task group mailing list about whether we need text clarifying the statement about which AMI parameters should be passed into the model by the EDA tool. ------------- Review of ARs: - Arpad to fix the description of "symmetric" in the clock_times clarification BIRD draft. - Done. - Kinger to update the PSIJ Sensitivity BIRD and send draft2 to the ATM list. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the October 4th meeting. Michael moved to approve the minutes. Curtis seconded the motion. There were no objections. -------------- New Discussion: clock_times clarification BIRD draft: Arpad reviewed new changes in a draft3a. He noted that the "symmetric around the horizontal axis" language had been removed, per previous discussions. Fangyi asked additional questions about the new language, particularly this sentence: When the dual input Data Rx AMI_GetWave function expects a waveform in its clock_times input, the raw clock times that the Data Rx AMI_GetWave function will use in sampling calculations are the times when the waveform crosses the horizontal axis (i.e., the zero crossings). Fangyi asked what we mean by "raw" clock times. Arpad said the Data Rx model may further modify the clock times from the "raw" clock times, which are the zero crossing points of the clock waveform passed into the Data Rx model. Fangyi asked why we need to say that the "raw clock times" are the crossing points. He asked whether we should simply state that the clock waveform is a differential waveform centered around zero. Arpad said that had been suggested before, but he wondered whether we want to assume the clock will always be differential. Fangyi noted the section on the DC_Offset parameter, and he said that AMI always assumes the output of an Rx AMI_GetWave is zero-centered. This is what we do for single-ended DQ simulations. In theory, we shouldn't have to mention any of this in this section because it is implicit that the waveform output from the clock (DQS) model is already zero-centered. Arpad and Fangyi discussed ways to clarify the language, and Arpad suggested the fine points of this discussion be taken offline. Arpad said he had some important new questions about clock_times and the relationship between clock values returned in clock_times and the waveform data in the call to AMI_GetWave that returned them. He started with a normal SerDes model question. He noted text about clock_times on page 229 in IBIS 7.1: ... regardless of whether that waveform sample occurs in the waveform segment being returned by the current call to AMI_GetWave, or in the waveform segment to be returned by the next AMI_GetWave call. Arpad said this implied the model could return values in clock_times corresponding to the next block of waveform data. He asked whether this was restricted to adjacent AMI_GetWave calls only. Conversely, could a "lazy" CDR model wait for 10 AMI_GetWave calls before deciding to return clock_times corresponding to all 10 blocks of waveform data? Curtis said that a model is not allowed to wait and return more clock times than would correspond to the block of waveform data in the given AMI_GetWave call because (also on page 229): ...The clock_times vector is allocated by the EDA tool and is guaranteed to be greater than the number of clocks expected during the AMI_GetWave call. Therefore, the model would be in error if it were to assume it could return more clock times than would be expected for the block of waveform data in that AMI_GetWave call. It certainly could not expect to return 10 blocks' worth of clock times all at once. Arpad agreed. Arpad said that while the number of clock times being returned was bounded by this language, the question about the location of those clocks with respect to the waveform data in that AMI_GetWave call was still open. He said that the language for SerDes states that the returned clock times values could correspond to the next AMI_GetWave call. Does this same freedom apply to the clock times returned by a Clock Rx AMI_GetWave to be consumed by a Data Rx AMI_GetWave? He noted another sentence in that section: ...there is no requirement that there be any relationship between the clock ticks generated by clock_times and the actual waveform returned in the primary channel. Ambrish asked what the point of this sentence was meant to be. He said it appeared to be explicitly stating that we don't want to force clock times returned to correspond with the waveform data in that block. Arpad said he wasn't trying to add any new requirement, but he was trying to understand what the specification expects models to do. Arpad said he was asking the question, along with his development team, because they were in possession of a set of DQS/DQ models that did not work properly unless the tool intervened to synchronize the clock times with the DQ data. For example, if the first Data Rx AMI_GetWave call received 4000 UI worth of waveform (covering 0 to 2us), and the tool passed in 4000 clock times in the clock_times vector but the clock times were advanced by 4 UIs, the last four clock times were dropped inside the first AMI_GetWave call (and were not retained for the next AMI_GetWave call) because they were past the end of the 2us long block of waveform data. They had to make sure that their tool would only pass clock time values into the clock_times vector that were within the time span of the data waveform. Walter said he would question the behavior of the model in that case. Arpad said he can't question the model if the specification doesn't disallow what it is doing. Randy said if you have a clock coming out of a DQS model, and it's supposed to be the input timing for a DFE in the DQ model, then you need to have a phase relationship. Arpad agreed, but he said in the SerDes case we expect the tool to buffer the additional clock ticks and use them later. In the case of these dual input Rx models, we should either require the DQ model to perform this buffering of the clock times internally, or require the EDA tool to make sure that the clock times are matched with the time span of the data waveform. Fangyi said this question pointed out a fundamental flaw with the "Times" setting of Rx_Use_Clock_Input. He said the DQ model cannot buffer times in the way an EDA tool might for SerDes because the DQ model is obligated to return a processed output waveform with the same amount of data that it receives as input. If, for example, the DQ model is given 100 bits of data waveform, then what can it possibly do with that block if it were only given 50 bits worth of clock_times by the DQS model? Walter said there was no fundamental difference between "Times" and "Wave" operation. With "Wave" the model is passed a DQS waveform corresponding to the same time as the DQ waveform. The "clock times" in this case are just where that DQS waveform crosses zero. You could always have an issue with getting the exact number of clock times, and you have to write your model to handle overlap-and-save to deal with issues such as one crossing/clock being shifted out of the range of a block of data by jitter, etc. Arpad asked what the solution for this issue would be. Fangyi said he thought we might need to eliminate "Times" as an option. Randy said that IBIS 7.2 will be held up waiting for a resolution to this question. - Randy: Motion to adjourn. - Bob: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 18 October 2022 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives